In this lab, you will create the incus VTP containers.
In the first part, you will work together in your group, to set up a single “vtp-proxy” container on your host, and to upload the shared image files.
In the second part, you will work individually to create your own individual lab environments on the host, and perform some changes.
To avoid having to fetch large images over the class Internet link, your instructors may have provided a local image server.
If they do, they’ll tell you how to add it as a remote, for example:
incus remote add ttt https://ttt.nsrcwork.shop:8443/ --public
(accept the fingerprint when asked). Test it like this:
incus image list ttt:
Then when following the instructions, replace with prefix
nsrc: with ttt:
Working together in your group, follow the instructions for VTP Proxy.
This includes launching the “vtp-proxy” container, and running the
sslsetup script. For now, enter “none” when prompted for
the domain.
Once done, you should all be able to access
local.nsrc.org in your browser, which will redirect you to
https://local.nsrc.org
with a valid certificate and a holding page.
Still working together in your group, you will need to fetch the shared images that all your campus containers will use, as described at https://images.nsrc.org/docs/topology/overview/
The files you need are:
x86_64_crb_linux-adventerprisek9-ms.17.18.02.iolx86_64_crb_linux_l2-adventerprisek9-ms.17.18.02.iolnsrc-nmm-incus-20241016-bd0b96f0.qcow2Check whether you already have them:
incus exec vtp-proxy -- ls -lR /vtp/shared/images
It’s OK if you see
No such file or directory: the directory will be created when you first upload an image
If not, download these onto your server. Talk to your instructors about where to fetch them from. The third one is normally hosted at https://images.nsrc.org/vtp-shared/images/QEMU/nsrc-nmm-incus-20241016-bd0b96f0.qcow2 but as this is a large file, they should provide a local copy for faster access.
Once the files are on your server, push them into the vtp-shared storage volume:
incus storage volume file push \
x86_64_crb_linux-adventerprisek9-ms.17.18.02.iol default vtp-shared/images/IOU/ \
-p --uid 0 --gid 0 --mode 755
incus storage volume file push \
x86_64_crb_linux_l2-adventerprisek9-ms.17.18.02.iol default vtp-shared/images/IOU/ \
-p --uid 0 --gid 0 --mode 755
incus storage volume file push \
nsrc-nmm-incus-20241016-bd0b96f0.qcow2 default vtp-shared/images/QEMU/ \
-p --uid 0 --gid 0 --mode 644
Check again:
incus exec vtp-proxy -- ls -lR /vtp/shared/images
Working individually, you’re now all going to create your own lab container.
You will be using the Campus Network Design and Operations lab,
single campus version. This is cndo1, as opposed to the
normal cndo which has six campuses.
Choose a name for a container: say <yourname>. If
there are several people in the group with the same name as you, then
agree between yourselves unique container names to use!
The instructions are at https://images.nsrc.org/docs/topology/cndo/ but you will
need to change the image name to cndo1 and choose
“yourname” for the container name. That is, launch the container
using:
incus launch ttt:cndo1 <yourname> -p vtp
(without the angle brackets)
Once this is done, you should be able to enter
<yourname>.local.nsrc.org into your web browser, and
get the students’ view to your lab.
Click on Campus 1, Console > bdr1
You should get a shell on the bdr1 router. Hit Enter to get the
Router> prompt.
Note
If it does not connect, or you see only “Choose a console”, then see “debugging” below, and/or talk to your instructors.
When you get the prompt, continue to configure an interface:
enable
conf t
hostname bdr1-campus1
int e0/1
ip address 100.68.1.1 255.255.255.240
no shut
end
wr
# Hit enter to [confirm] overwriting the nvram
Now connect to Campus1, Console > core1,
and do some similar configuration:
enable
conf t
hostname core1-campus1
int e0/0
no switchport
ip address 100.68.1.2 255.255.255.240
no shut
end
wr mem
Finally, check if you can ping 100.68.1.1 from core1. If so, you have a working point-to-point link inside GNS3!
Check if your container is running:
incus list <yourname>
If it’s running but there’s a problem with the GNS3 topology starting, you may get some idea from looking at gns3 logs:
incus exec <yourname> -- journalctl -eu gns3
An error like
Aug 11 15:12:02 brian gns3server[700]: No configuration file could be found or read
means that you probably didn’t run sslsetup in the proxy. Or maybe
you forgot to apply the profile (you missed -p vtp when
creating it), in which case you can fix by:
incus profile apply <yourname> vtp
incus restart <yourname>
Also, check if you can login to the GNS3 web UI (from the index page:
Admin > GNS3). To find the credentials:
incus exec <yourname> -- cat /etc/gns3/gns3_server.conf
If this works, then open the project and start the devices. If there are missing files, you should get an error about them.